COMMENT ⊗   VALID 00030 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00004 00002	@BEGIN<TitlePage>
C00006 00003	@Chapter[Introduction]
C00010 00004	@Chapter[Just what @i{is} an Analogy?]
C00012 00005	@Section[Similarity]
C00019 00006	@SECTION[Analogy - Informal]
C00024 00007	@SubHeading[Types of Analogy Tasks]
C00029 00008	@Chapter[Simple Analogy Examples]
C00032 00009	@Section[Case I - Formal]
C00040 00010	@Section[Case II - Informal]
C00043 00011	@Comment{ Fred/Jill cases }
C00047 00012	@Comment{ Intro to Brand X(s) }
C00048 00013	@Chapter[Mapping]
C00049 00014	@Section[Feature to Feature Mapping]
C00057 00015	@Section[Symbol to Symbol Mapping]
C00061 00016	@Section[Summary of Mapping Approach]
C00067 00017	@SubHeading[Difficulties]
C00073 00018	@SubHeading[Other Issues: Reformulation]
C00078 00019	@Chapter[Commonality]
C00080 00020	@Section[Common Theory]
C00084 00021	@Section[Common Class]
C00089 00022	@Section[Summary of Commonality Approach]
C00095 00023	@SubHeading[Other Issues: Learning]
C00098 00024	@Chapter[Answer: Common theory + Mappings]
C00101 00025	VII. Remaining issues:
C00104 00026	@Chapter[Remaining Issues]
C00106 00027	@Chapter[Acknowledgements]
C00107 00028	@CHAPTER[Notes]
C00117 00029	@Unnumbered[References]
C00118 00030	@BEGIN[Comment] 	Outtakes
C00121 ENDMK
C⊗;
@BEGIN<TitlePage>
@TitleBox{
@MajorHeading[What's in an Analogy?]}

@i{@Value<Date>}

@Heading{Russell Greiner @C[and] Michael R. Genesereth}
@B[Heuristic Programming Project
Computer Science Department
Stanford University]

@BEGIN[TEXT, Indent 0]
@C<Abstract>: @i{
It is quite tempting to view an analogy as a mapping between
the parts of the two analogues.
Unfortunately there are several limitations inherent in this approach.
This paper will discuss these deficiencies,
and then present several refinements of this characterization of analogy;
discussing their respective advantages and problems.
This survey culminates with a definition which seems adequate
to handle all common uses of analogy.
The conclusion addresses a few of the issues 
-- both conceptual and at the implementation level --
which must be resolved before this definition can be used.}
@END[TEXT]

@END<TitlePage>

@Chapter[Introduction]
@LABEL{Intro}

The purpose of this paper is to motivate and present a 
compresensive definition of the elusive term, @i{analogy}.
Much of its emphasis, and many of its biases, can be credited to
our overall goal -- designing a general "Analogizing" program.
(See @Cite[ThesisProp] for more details.)

Chapter @Ref[QuickDefn] begins with a coarse "naive" description of analogy;
specifying the types of situations which 
(for our purposes)
do, or do not, qualify as an analogy.
Chapter @Ref[Examples] then lists a small body of quick, "local" examples;
whose breadth is (or at least seems) sufficient to span
the significant different cases,
covering both formal and informal situations.

Several proposals for a "comprehesive" definition of analogy
follow this overhead.
After discussing the positive aspects of each such "straw man",
we demonstrate its inherent limitations
by listing some "obvious, standard" analogy problems
(taken from Chapter @Ref[Examples]) 
which cannot be handled by this formalism.

Taken together, these cases motivate the 
"correct"
view of analogy, presented in Chapter @Ref[Answer].
This chapter will explain why (we feel) this model "works"
-- that is, can be used to handle a wide range of
(perhaps all?) 
analogy problems/situations.  

The next chapter, @Ref[Issues], discusses some of the remaining issues.
These are points, both minor and major, which must be resolved before
this description of @i{analogy} can be considered complete --
that is, sufficiently detailed to actually implement.

----

<<here - write this after rest of paper>>
examines at this particular definition of analogy in depth;
commenting first on its advantanges and generality, and then discussing some of
its problems -- especially those which make it difficult to actually implement.

?? Various appendices will cover additional things -- such as expected properties
of analogies (to be exhibited by any model/implementation...) and ...

@Chapter[Just what @i{is} an Analogy?]
@Label{QuickDefn}

To ground this discussion on analogy, it is essential to specify 
(at least superficially)
just what we will mean (and, importantly, do not mean) by the term analogy.
We will begin by formally defining a weaker notion, of similarity.
While this relation is NOT our objective,
It does serve to start our discussion of analogy.
After hinting at how similarity is related to analogy,
and then indicating why it is not sufficient,
we will present a quick sketch of an analogy.
That overview will help the reader focus on the "kinds" of analogies
this paper is attempting to explain, and on the types of
"analogizing tasks" it is considering.

@Section[Similarity]
@Label{Similar}

Our intuitions tell us that two things can only be analogous
if they are (somehow) sufficiently similar.
But what does it mean to be similar?
A natural notion of similarity (which we will use) defines
two objects to be similar @i{iff} there is a set of features which they share.
For example, we could claim that RDG and MRG are similar in that
each is a person, lives in Palo Alto, is associated with Stanford, etc.

@SubHeading[Formal]

We can formalize this by making @i{SIMILAR} a tertiary relation,
whose three arguments are all <Symbol, Theory> pairs.
The expression
@BEGIN[Example]
@i{SIMILAR}( <A@-{1}, TH@-{1}>, <A@-{2}, TH@-{2}>, <UNIF, COMMON> ),
@END[Example]
will mean that the analogue A@-{1}, described by the theory TH@-{1}, is similar
to A@-{2}, described by the theory TH@-{2}, with respect to the
theory COMMON.@Foot{
Actually COMMON might be merely a list of axioms -- 
it need not be their deductive closure under @i[modus monens].}
This statement is true if each statement in the theory COMMON
maps into a statement of TH@-{1} (resp., TH@-{2}) using mapping 
@g(s)@-{1} = @K[LeftDoubleBracket]A@-{1}\UNIF@K[RightDoubleBracket]
(resp., @g(s)@-{2} = @K[LeftDoubleBracket]A@-{2}\UNIF@K[RightDoubleBracket]).
Stated another way,

@BEGIN[Example]
COMMON @K[SUBSET] TH@-{1}@K[LeftDoubleBracket]A@-{1}\UNIF@K[RightDoubleBracket] @~
@K[Intersection] TH@-{2}@K[LeftDoubleBracket]A@-{2}\UNIF@K[RightDoubleBracket].
@END[Example]

Intuitively, COMMON contains those facts which are included in both theories,
modulo the actual names of the analogues.
Each TH@-{i} theory might house
additional facts about that A@-{i} analogue,
facts which are not included in COMMON.
Note finally that each A@-{i} satisfies COMMON, in a model-theoritic sense.

@SubHeading[Example]

Continuing the MRG/RDG example began above,
suppose RDG was A@-{1}, and MRG = A@-{2};
and TH@-{1} included
@BEGIN[EXAMPLE]
(MEM RDG PERSONS)
(LIVES-IN RDG PALO-ALTO)
(ASSOCIATES STANFORD RDG)
(LAST-INITIAL RDG G)
(AGE RDG 27)
(PREFERED-RECORDER RDG ALTO)
@END[EXAMPLE]

and TH@-{2} included
@BEGIN[EXAMPLE]
(MEM MRG PERSONS)
(LIVES-IN MRG PALO-ALTO)
(ASSOCIATES STANFORD MRG)
(LAST-INITIAL MRG G)
(AGE MRG 31)
(PREFERED-RECORDER MRG BASS)
@END[EXAMPLE]

Then we could construct a COMMON theory of
@BEGIN[EXAMPLE]
(MEM ? PERSONS)
(LIVES-IN ? PALO-ALTO)
(ASSOCIATES STANFORD ?)
@END[EXAMPLE]

It should be clear that
@BEGIN[EXAMPLE]
@i{SIMILAR}( <RDG, TH@-{1}>, <MRG, TH@-{2}>, <?, COMMON> ).
@END[EXAMPLE]
Notice that COMMON could have included 
@BEGIN[EXAMPLE]
(LAST-INITIAL ? G),
@END[EXAMPLE]
but didn't.  
Also, note the analogue('s name) was allowed to occur in any position of the
proposition.

@SubHeading[Critique]

There are several aspects related to this @i[SIMILAR]ity relation
which should be discussed.
First it is quite tied to representation -- the particular encoding
scheme used to store a fact may determine whether it participates in
a similarity connection.
Had we used
@BEGIN[Example]
(ASSOCIATED-WITH MRG STANFORD)
@END[Example]
to indicate MRG's association with Stanford rather than 
@BEGIN[Example]
(ASSOCIATES STANFORD MRG),
@END[Example]
[while RDG retained the 
@BEGIN[Example]
(ASSOCIATES STANFORD RDG)
@END[Example]
form of this type of assertion,]
this fact could not be included in COMMON.

Second, a more serious issue is "how does one use this connection?".
It merely explicates every syntactic connection which might join
A@-{1} to A@-{2}.
Now what?
Knowing that A is similar to B does not tell us anything new
(nor even any plausible conjectures)
about B.
As we will soon see, seeing that A is analogous to B is more useful,
as it can lead to additional conjectures about B.

@SECTION[Analogy - Informal]

For our purposes, an analogy is a relation 
which conneCts a pair of objects/events/things/...,
(hereafter called "analoeues")
and involves other (to be specified) parameters.
The purpose of this paper Is a more exact qpecification od this relation
-- resolving, in particular, what those other arguments to this
Analogy relation are.

Taking a more procedural (@i{i.e.}, leqs relational) view,
we can ask what is the "analogy" which should then be returned
by our general purpose analogizing program?
And what should be its inputs,
besides (descriptions of) the two analogues?
A "mappist", foR example, would claim that the analogues are sufficient input,
and the returneD analogy is siMply
the mapping function which carries each relevant Part/featuRe of one analogue
into a corresponding part/feature of the other.
We will see later that this is NOT sufficient;
as there is more which must be specified.
(See Note @Ref[Gen-Use].)

The fact that we are talking about two analogeeq doeq FOT
restrict us to siMilarity analogies;
this formalismcan Readily handle propoRtional analkgiepεACf↓oCYX8@@~∃QQJAiISGVA!KeJA%`
βSconvert the proportional analogy,
@i[A:B :: C:D], into a similarity analogy, whose analogues are the terms
@i[REL(A B)] and @i[REL(C D)],
where
@i[REL(@g<a> @g<b>)] denotes a relation which holds between
@g<a> and @g<b>.
We can now talk about this pair of relations, as we could any other object.
(Bravo for second order languages.)

However, as we are dealing with @i{pairs} of analogues,
we are NOT considering familial relations,
which deal with n-tuples of analogues or their features.
(This class includes cases like "all mammals are similar", and
"one can put the jaw bones of all mammals into correspondence",
or even the class of all familial analogies.)
We do, however, feel that a relatively
straightforward modification to
our approach will enable us to deal with such cases.

@SubHeading[Design Constraints]

Our goal is an ANALOGY relation which conforms to our
(well, my)
intuitions.
Hence, it will
be based on the @i{commonality} of the two analogues,
as was the similarity relation defined above.
We will also insist that any two things can be analogous,
where, of course, some analogies
will seem more natural/useful/meaningful than others.
Also, the analogues themselves are usually not enough to uniquely specify
an analogy -- in general there are many possible analogies joining
a pair of objects.
(Again, some of which seem "better" than others).)

@SubHeading[Types of Analogy Tasks]

<<here: merge in:
Consider case of "A is more like B than like C"
(as in "People are more like doors than like windows")
need to determine how B and C different, within constraint that each
is like A>>

@Cite[NaiveAnalogy] described a large number of analogizing tasks,
including "find something similar to this analogue" and
"given two analogues, find the best connecting analogy".
This paper will specify the types of analogizing inferences formally.
The derived formalism will be sufficiently general that it will be able
to encompass any of these.

Broadly stated, there are two basic categories of analogizing tasks.
The goal of the some tasks is to form,
or fill out,
an analogy.
(See Note @Ref[TwoCases].)
This involes finding appropriate values for the as-of-yet unspecified
(or underspecified)
arguments of ANALIGY relation.
The canonical example of this is to deduce
the analogical connection which joins two well-specified analogues.
Another case is finding the secOnd analogue,
Given the first analogue and a description of the analogy.

Each member oF the other category uses such a "complete" analogy,
in some way
-- e,g. as an inference step, or via some set of (non-meta-leveL) rules.
The standard case here iS deduce (or conjecture) some new fact about
one of the analogues, based on some assertion about the other, and the
realization that they are analogous.
Other tasks deal with one or more derived analogies @i{qua} objects
of study --
for example, selecting the best analogy, within some situation.
(This, of course, requires a measure to evaluate how good each analogy is.)

In standard usage this distinction 
-- of generating a new analogy, versus using a known analogy --
is often blurred.
In one typical situation,
the goal is to derive some (previously unrealized) fact about one analogue,
using a still to be deduced analogy.
Here one has first to generate the analogy, and then use it.

The task of generating the analogy is seldom "pure" either.
One often has some guidance,
to constrain the type of analogy which can be found.
That is, there iS usually some additional constpaint
which helps to restrict the value of those other parameters
of the ANALOGY relation.
For this reason, @Cite[NaiveAnalogy] used the
@BEGIN[Example]
"A is like B, within constraint @G[a]."                (*)
@EN@[ExamplE]
to pose all such analogy problems.
It was within this context that one would conjecture assertions
vhich might hold about A, giveN some known fact about B.
Note that that doCument 
αnever Defined what tyPe of this thatconstpa`∪]PXA↓∂mC:Ao¬f\~∃!KeJA]JAoS1XAG←9iS]k∀Ai↑A∃[aY←dAiQSLAM←e5CYSg4X∩¬C9HAoS1P⊃βπ'#↔7C"βS-β&+∪'≠*βS#↔≡)αα≡↑
uβ∂|¬g∨',≥⊗w'5aPPH D∧=↔π→<Vj<9<≠T⊂;X-Myz(λ←_;<
L<p∞FB "0q→v9bl_vx6 %pπd
∀4⊃)QSLAGQCAiKdAββC↔O,¬g'~⊂λ
M<⎇
|HλX-l8ε7c↑P1g@-prehensioN p	C↓≤[@~∩¬QPhV∞-v⊗@→0⊗@ pπiCI∃[@↔nN2π≡
⊂λm∧→88m∧~;<
O(≤p↔Zp¬ C=]P≠↔≤εFN}dλ&/'|X	-d≥~→$∞_: →λ4πf Ana`→↑α;W.5aPE>Tλ
m≥≠λ⊂⊃≠w9t@$er @C8Aβ@;∞c?∂'P¬εv:∞M|βy0vH0r2@1pCiJ↓←]@2β∀εNH⊂∀@4 is @¬E@∪∃∧εFxHα@]-l→<\nL8π $λAC@3bβ?2∞Mε/≡QQ"j↓(≥~≡λ∩ 9K⊂4s⊂~z⊂$@3 abl@∀A`∪<∧εW<αP:4→P1`/↓9]KGi%←\
∀π#=β∞¬pM8⎇≥.(≤p↔Zp¬ New a@fπ≠↔KSL¬vw~≤&␈/Dml(≠`→λ10∂@i A@∨→∧εFF*≥f∞f|}V/~βC"A⊂¬'7@te thIpεA[
ε;Mβ&CπQβ&C∃βπv3 >⎇∀εO/>@λ4y1@4 be @≥K]Ke¬iKH_↓C]HAβ##↔_hSGO⊗∧@A⊃R⊃0↔_p¬ this i↓9m←Ymα+@~ε-p

∧≥~0_→yP7@& a`≥β1←GBAβ#gC↔~aβ'↔w#'?;,!βπ⎇3∃(∀Ph"S#*β3'O β↔3|εrε≡|¬P∩\αs a↓oSIJ↓caKεβ#@↔9(∪l⊂1pyYyPεET¬ ranging froM rery pre@
SgJA¬]HAMα{@⊗↓8;↓PXX<l\λ≠p↔λ⊃22@%p under`→LK;≥β≤¬⊗NNβ_<M≡~94d¬β"P~≠P92f_z4{"[<P9t_v67kH0p∞@Hαβ';≠⎇∪7π⊃∧ε6Nn≥H↔εOM≤W5A"U
<y(∞⎇9≠λ,(_`↔Xy1rf≡P24{~r2b~w:7P≥9wP!≤7pr ⊃7wz=Xw2⊂']2y60\4w3␈βE1v0\yryP≠s⊂2l_vx6"\P⊗VP≠0q2v~2r⊂3≠y6pvλ;2y9]yP4w→7y6p[↔εE∀∪7z2P⊂)2s-Q4vynH892yYw:9P_P1zjλ7s⊂:~2P24[rw9t[w9P;Z4qt⊂_wzv2λ12FE≥yrr⊂≥5P9x→qts<H0w⊂0[0v7s↑P1pyYV⊂;t]44w⊂≥44yP→7y6p]↔∀FE⊃pqt⊂_pyrP≥tv6⊂_2P3'[67{rY⊂;tz~⊂0P(]tquP_w2⊂4[37y6Xv⊂9z_ormat shown above,
in (*).
In each case both analogues have already been named, 
and there is some indication of the inter-connecting analogy.
Furthermore, we can assume the "hearer" is familiar with
(@i{i.e.}, knows lots of facts about)
at least one of the analogues.
The canonical task, now, is finding some new properties of the other analogue,
based on that 
"triggering"
analogy description.

@Section[Case I - Formal]
@Tag[Formal]

Consider the task of deducing some new fact about
@B[INTEGERS],
@Foot{
This general structure, @B[INTEGERS],
consists of both the obvious universe of elements,
and of the wide range of relations pertanent to these members --
including the functions @K[PlusSign], @K[TIMES], @i[Successor], ...
relations like @i[>] and @i[Divides], and constants like @i[0] and @i[1].}
based on knowing some fact about @B[RATIONALS].@Foot{
... which similarly includes several of its operations and constants
as well as universe of members.}
This requires two steps --
first determining how 
@B[INTEGERS] was analogous @B[RATIONALS], and then using
this analogy.

Example questions include:
@BEGIN[ITEMIZE]
What is true about < @B[Z],@K[PlusSign],@i{0} >?@*
@w(    )A: It is a group.

Is @K[PlusSign] associative, over @B[Z]?@*
@w(    )A: Yes.

How is @B[INTEGERS] like @B[RATIONALS]?
@w(    )A: Each embeds a group structure.
@END[ITEMIZE]

@SubHeading[Totally Specified Analogues, Precise Analogy]

Suppose we are told that@*
@i{The integers, under addition, with the zero element 0, are like
the rationals, under multiplication, with the zero element 1,
(in that each structure is an instance of a group)}
-- symbolically
@BEGIN[Example]
< @B[Z],@K[PlusSign],@i{0} > @K{BarTilde} < @B[Q],@K[Times],@i[1] >		(**)
@END[Example]

@COMMENT[That @B(Z) should be Integers - Z with a line thru it;
and @B(Q) should be Rationals - Q with a line thru it.]

Before asking what this means, consider what we can do with this information.
For example, if we know some fact about @B[Z] and @K[PlusSign], for example, that
the @K{PlusSign} operation is associative, we can then conjecture that @K[TIMES]
might be associative over @B[Q].  (... and, lo and behold, it is!)

(Now,) what does (**) mean? 
As an instantiation of a group, each structure satisfies the following
axioms:@FOOT[
We could, in fact, even state that each structure is an infinite,
(of cardinality @g[w],) Abelian group 
-- but that digression is not important here.]

@BEGIN[Example]
Set( Univ(G) )

Zero(G) @K[MemberOf] Univ(G)

BinaryOperator( Oper(G) )

Associative( Oper(G) )
  (i.e., @K[ForAll] x,y,z @K[MemberOf] Univ(G).
             [(x Oper(G) y) Oper(G) z] = [x Oper(G) (y Oper(G) z)] ]

Identity( Zero(G), Oper(G), Univ(G) )
  (i.e. @K[ForAll] x. x @K[MemberOf] Univ(G) => (x Oper(G) Zero(G) ) = x. )
@END[EXAMPLE]
@NOINDENT()where
@i[Univ(x)], @i[Oper(x)] and @i[Zero(x)] are unary (skolem) functions
mapping a structure into its parts;
which here extracts the first, second and third elements of a triplet,
respectively.

This case is, of course, a gross simplification of any real world situation,
in (at least) three ways, all of which will be addressed below.
First, notice that we were already given both structures,
and thereby told, explicitly, both which aspects of @B(Z) to consider,
and how to consider these facets.
In addition, we have been explicitly given the theory
which both of these structures satisfy -- group theory.
(That is what makes that (supposedly analogical) inference above so trivial
-- the associativity of the operation over the universe is automatically true
in any group.  Yawn.)

@SubHeading[Partially Specified Analogues, Precise Analogy]

Now imagine being told only that the general structure, @b[INTEGERS],
is similar to the structure @B[RATIONALS],
in that each is an instance of a group.
Here any analogy task first would require the hearer to
specify which @b[INTEGERS] (resp., @b[RATIONALS],) things correspond to the 
group things -- universe, operation and zero element.
Hence the correspondences could be
@BEGIN[EXAMPLE]
< @B[Z],@K[PlusSign],@i[0] > @K[BarTilde] < @B[Q],@K[Times],@i[1] >
{ND[EXAMPLE]
(as it was before,) or
{EGIN[EXAMPLE]
< @B[Z],@K[PlusSign],@i[0] > @K[BarTilde] < @B[Q],@K[PlusSign],@i[0] >,
@END[EXAMPLE]
or even
@BEGIN[EXAMPLE]
< @B[Z]@-{7},@K[Times]@-{7},@i[1@-{7}] > @K[BarTilde] < @B[Q],@K[PlusSign],@i[0] >,
@END[EXAMPLE]
(the above notation refers to the integers mod 7, under multiplication).

@SubHeading[Partially Specified Analogues, No Analogy Given]

Now suppose we were only told that these structures are similar, but not how --
@i{i.e.}, we were not given that each should be consider as a group.
Perhaps we should consider both as rings, or monoids, or lattices, or ...  
There are arbitrarily many connections one might make -- both those deriving
from some mathematical structure, and otherwise.
(Recall the famous "consecutive subway stops in NYC" example).

@Section[Case II - Informal]
@Tag[Informal]

In all of these cases, we were dealing with artifical objects;
and in the first two cases, the desired commonality was equally man-made.
The third loosening occurs when the analogues refer to natural,
rather than artificial, objects.
With artificial objects, (such as integers,)
we have access to essentially every pertanent fact
(Godel's Incompleteness Proof notwithstanding)@Foot<
This is not quite true -- there are various "meta-level" facts
about the integers which are not covered by the standard body of defining
facts.  For example, who first "discovered" them, or the contents of some early
theories about them, @i{etc}.>.
When talking about natural objects, like Fred or democracy, however,
we are forced to deal with only an abstraction of the analogues --
that is, all we have is a partial description of the object.
Note @Ref[NeedReform]
discusses why this observations leads to the need for reformulation.

Enough overview.
Below we consider what natural sounding ways of suggesting an analogy.
Each consitutes a description for constraining how these two things can
be analogous.
(Recall that, in many cases, these would not need to be stated explicitly;
this additional information can often be understood implicitly.)
The descriptions below can also be used to (partially) define the analogy --
that is, they can indicate how the analogues map into one another.
(Once again refer to Note @Ref[Gen-Use].)

@Comment{ Fred/Jill cases }
Fred is [just] like Jill
@BEGIN[ENUM1]
@ux<in that both are> lawyers.@*
@TAG[BothAre]
Or: @ux<as both are>, @ux<regarding both to be>, ...@*
@i{I.e.}: both are in the same category or class; and this comparison should
be based on this perspective.

@ux<in terms of> profession.@*
@TAG[TermsOf]
Or: "<Adjective>ily, A is like B", as in "Cognitively, people are like computers."@*
@i{I.e.}: both are in the same category, based on the <Adjective> perspective.

@ux<considering only their> height.@*
@TAG[Consider]
Or: @ux<based only on>, @ux<considering just>, 
@ux<where> X @ux<are the most salient attributes.>@*
@i{I.e.}: The value of their respective X slots [here height] are the same (or similar).

@ux<except that> Jill is female.@*
@TAG[Except]
Or: @ux<were it not that>, @ux<disregarding the fact that>, ... @*
@i{I.e.}: Some implicit, unstated slot [here gender] has a different value.

@ux<ignoring> gender.@*
@TAG[Ignore]
Or: @ux<excluding>, @ux<disregarding>, ... @*
@i{I.e.}: The value of their respective X slots [here gender] are different.

@ux<after substituting> CalTech @ux<for> Stanford.@*
@TAG[Substitute]
Or: @ux<except in> X @ux<context rather than> Y, 
@ux<but deals with> X @ux<rather than> Y, ...@*
@i{I.e.}: There is a strong (@i{i.e.g.}, causal) reality to the 
proportional metaphor@*
@w<    >Fred:Jill :: CalTech : Stanford@*
There is some relation joining Fred to CalTech holds for Jill and Stanford.

@ux<as> Prince Charming @ux<is to> Cinderella.@*
@TAG[As-Is-To]
Or: @ux<a la> Prince Charming @ux<with respect to> Cinderella, ...  @*
@i{I.e.}: (At least) one of the relations joining Prince Charming to Cinderella
links Fred to Jill. Perhaps "loves enough to search for"?
(This is much like the case above.)

@END[ENUM1]

Notice that these @Ref[As-Is-To] cases can be divided into three general
categories.
Cases @Ref[BothAre], @Ref[TermsOf] and @Ref[Consider] are all "positive",
in that we are (indirectly) specifying the presence of some feature shared
by both analogues.
Next, cases @REF[Except] and @Ref[Ignore] both indicate some "negative" feature --
some property which only one of the analogues has (or is known to have).
Finally, cases @Ref[Substitute] and @Ref[As-Is-To] seems "substitutive" --
indicating that some feature which held for one analogue holds, 
@i{MUTATIS MUTANDIS}, for the other.

@Comment{ Intro to Brand X(s) }
To motivate our view of analogy, it is necessary to 
"undermine the competition.".

The next two chapters present the dominant views of analogy,
@i{viz.}, as a mapping, and as a commonality.
We will use the examples presented in this chapter to
illustrate the strengths and weaknesses of both of these approaches.

Each chapter will close with an evaluation of that perspective.
We will discuss which types of analogizing tasks this formalism
can and cannot handle,
and then describe how easy those attainable tasks are.

@Chapter[Mapping]

This chapter presents two views of analogy, both based on mapping
from one analogue to the other.
We will critique each approach seperately,
and then conclude this chapter with some general reasons why
this mapping approach to analogy is inadequate.

@Section[Feature to Feature Mapping]
@Label[F-F]

This is the most common approach to analogy --
@i{A} and @i{B} are similar whenever their parts@Foot{
By "part" we are referring to some @i[part] of the description of the analogue,
not necessarily sub-pieces or components.
Hence a "part" of Elephant may be its Color.
For our purposes, we think of any slot and value as a part of the concept.}
(or some relevant subset of them)
can be shown to correspond.
(This is verified by perusing @Cite[M&T],
and observing how many researches take this position.
See also the (non-AI) references @Cite[Hesse] and @Cite[Black];
and the AI @Cite[Evans], @Cite[Kling] and @Cite[Winston].)
The most straightforward way of encoding this uses the Unit/Slot/Value
notation, as discussed in @Cite[Frame].

This approach works nicely for many of the Fred and Jill cases 
given in Section @Ref[Informal].
The Positive Cases are handled trivially.
The "@ux<both are>" case, (@Ref[BothAre]),
which claimed they both are lawyers,
is tantamount to noting that the value of their respective 
@i{Profession} slots agree --
@i{i.e.}, @b{Fred}:@i{Profession} = @b{Mary}:@i{Profession},
both equal "Lawyer".
The "@ux<in terms of>" claim, (@Ref[TermsOf]:
in terms of sharing the same profession,) is even more obvious.

The values found need not be equal -- often similarity is sufficient.
(Of course this does lead a recursion...)
For example, Fred and Jill might be considered analogous
because the respective ancestry was similar --
@BEGIN[EXAMPLE]
@B[Fred]:@!@I{AncestryFrom} = @!Romania
@B[Jill]:@/@I{AncestryFrom} = @/Hungary.
@END[EXAMPLE]
Now we have to show that Romania and Hungary are similar.
The similarity criteria for these values may be context dependent --
based on the different base units.
Note @Ref{ContextDep} discusses this point.

The Substitutive Cases seem to work well also
-- often requiring little more than a simple lexical substitution.
For example, one could handle the
"@ux<after substituting> CalTech @ux<for> Stanford" case
by scanning the @b[Jill] unit for the the value "Stanford", and replacing
all such values with "CalTech".
(It might require some other checks, which we won't discuss here.)

The negative cases,
"@ux<except that> Jill is female" and "@ux<ignoring> gender",
can also be fudged, by, once again, first noting where the value
and slot name, respectively, occur in the @b[Jill] unit, and 
then dealing with that slot/value situation accordingly.
One solution would involve mapping Female to Male;
another would be to simply disregard this @i{Gender} slot altogether.

Now consider how to apply this simple feature mapping approach to
the more formal cases, as examplified in Section @Ref[Formal].
As in that example,
these situations are often characterized by noting that both analogues 
contain similar embedded structures
-- similar in that each of these substructures satisfy a certain theory.
(In our example, we saw that
< @B[Z],@K[PlusSign],@i[0] > @K[AsymptLTE] @B[INTEGERS] and 
< @B[Q],@K[Times],@i[1] > @K[AsymptLTE] @B[RATIONALS],
and that both substructures satisfied the group theory@FOOT[
The @K[AsymptLTE] relation means embedded substructure, of course.].)

This analogy is quite difficult to state,
given the restriction that all we can state is that
the value of some slot of the @B[Integer] unit must be similar (or equal) to
the value of the same slot of the @B[Rational] unit.

There are convoluted approaches which would work:
Perhaps this @b[Integer] unit could have a @i{Contains-Structure} slot,
whose value includes (a pointer to) the @b[Integer@u{Qua}Group] unit.
This unit, in term, would have a @i{SatisfiesTheoryOf} slot,
whose value was GroupTheory.
Similarly @b[Rational]:@i{Contains-Structure} = @b[Rational@u{Qua}Group], and
@b[Rational@u{Qua}Group]:@i{SatisfiesTheoryOf} = GroupTheory.
Given this, one could see that @B[Integer] and @B[Rational] are analogous,
as their @i{Contains-Structure} slots have similar values -- that is,
each of those respective referenced to units have a
@i{SatisfiesTheoryOf} slot whose value is GroupTheory.

It was problems of this sort which lead to the next refinement of
this mapping approach, in which relations, as well as "values of slots"
could be mapped over.  This is presented in the next section.

In summary, we note that this feature mapping approach is quite useful,
and quite efficient, but does run into some problems.
Its limitations are, unfortunately, quite extensive.
While this approach could indeed find analogies based
on the "ground term constants", it has a hard time
comparing the non-binary relations (as shown above),
and is all-but-unable to actually deal with the arbitrary relations
which may involve the analogues.
In Section @Ref[S-M], we will discuss the limitations 
associated with (both instances of) the mapping approach to analogy,
as well as give reasons for the characteristics mentioned in this summary.

@Section[Symbol to Symbol Mapping]
@Label[S-S]

In this section we will extend the feature to feature mapping 
to the more general case where one can map a set of arbitrary propositions
(in which one of the analogues participates) into a corresponding set
which involves the other analogue.
Viewing slots as binary relations, we see that this approach is a
proper superset of the previous feature mapping approach.
There one can only map terpiary propositions whose first arguments matched
and wheRe the analogues were in the second position.
(@I{I.e.}, just cases where the values of slots changed.)

αHere not only may the values of the slots be cHanged0~∃EkPAoJA
C\AI∃CXAo%iPAO∃]KeC0@Q]←β!β+W≥!β'vKe%¬∪↔3π&K?;Mph*'d⊗&&≡M⊗}rD∞v*ε<≥bεn≡∧ε}vT∞&.f≡M⊗}r¬λεO↑l\Wbπ=Iw'~∃APW≡
_6BεL\⊗g~∞⎇↔&B
⎇f*ε≥l⊗f}}XRbε⎇nFzε≥mw&F↑ πε.L≡FN}eaPREM
↔~ε\X⊗w~∞|Rπ>≥IBεv\XBε
∞8V≡}lDε␈⊗L↑"π∨≡8
](≥≠d≠h_-o=~~-lh~3NL<Y<nM;Yc↓QYyH=⎇<\lUJ#"JM~<h∞<[:.Nh≥4d∞≠h⊃
≡x⎇4n4→Y0.N8Y<d
yH⊃L\=≥0→→yP⊗VH37y→|0vx≠2V⊂*~0z⊂ 4he
Operation Featu@IJA←L↓↓E.LrR⊗≡-∩Nu0hS←#'≡Aβ'M∧α.nCe+NO'>ruβ'pβ?WI∧∧WF∞↑
F*b
~2ε∂>=v≡N≡M↔6*aQ hT\≥gJπYgεFT
ε∂6TFO≡>↑7≡∞D¬ε␈∩λ.VNgD∞7O∨L]W~ε,≡6."
xE∀≥~~.∀_8λ0rkacH
-- inclUdifg↓↓πSi∃3πCE	←]KY1C:X~)↓πSi∃3∂K]Q]Ke:0A↓πSQK7∂K9iUKe¬:PAC9HA↓π%iK7∪9iKeαK↔3∩jp4(Q)↔"ε≡4π'↔\Tπ&F≤APF∞β↑(≥X;≠l@|P7`.e cAn descp¬SEJ↓kgS]≤AiQSLAOK]∃aCISiKHA[¬aaS]≤ACaaI←CGP↓GC\@4∃EJA⊃KgGe%EKHAUgS@;8βS#∃πβK↔[L{WMβ4+πSW⊗)β7π¬β';≥εCCK}∂!⊂hS∨π[,qβS#*βπCC⊗{CK'∂#∃βO/!β/→∧∧f.∂NXL↑iC"JM→(_,NX;]≤βrP7Xα thiq a@Prkach is persp@∃GkSidXAS\↓aKe[LAWLA9k[EKH∩∀QC9HA]CQkeCY9KgfR↓←LAge[E←YLA]KKα#↔⊃⊂∧∧Vf.|≥f≡*Dλ	.LiC"H≥{\z,L<H∀≠{P:9~{4pvλ4z⊂ )pεAi↑↓K]G←⊃JAiQ∀AKCe1SCd~)↓Sw∪9iKOKI`
βπv!αKπ&K?;πe→βπK*β?S@β∨⊗βy$∞?β⊂"`8ampl@∀X⊂∀>K[↔9¬##∃β⊗+3πSL{;L4Tαα,y→e\/≥WεFXπ#!
x0
4\pε`∪KLQ∨K␈+BS#,{CE1βbα
nUi1αβMY.u1∧β&mBβP∂D¬ εE)Xz4yc~p¬s(Gph∂kaQQKO¬dX@y↓	7#*X↓↓S6UtXA↓Slc:`9αI0$
∧*2%8[ε∞o
H	+Q"C"JM→(≠L←≥λ∀l\⎇~3md≥z3
↓⊂24iXzyyP≥42P ,imatations ass@=GSCi∃H@~∃β0⊗O&∧


<h∪,≡≤~3LT_8_≤0πacH to @¬]CI←≥rvACLAgK→αaβπM¬∪↔C↔∂!βS#*βπ'l≥g&∞|Z2`H!Q @Section[Summary of Mapping Approach]
@Label[S-M]

This section will describe many of the advantages and disadvantages associated
with this mapping approach to analogy.
First we will discuss how successful this mapping formalism is at
describing different types of analogizing tasks.
This will lead to a discussion of which tasks
(of the ones which could be stated within this mapping formalism,)
are easy to solve,
and then to tricks which can be employed to solve the other
(statable)
tasks.
After this we will mention various remaining aspects of this approach.

The mapping approach has many
(quite seductive)
advantages.  
First, this formalism is sufficient to describe almost any type of analogy task --
covering both "analogy finding" and "analogy using" categories.
Second, most of the "analogy use" tasks can be solved quickly and efficiently
-- many require only a relatively simple and straightforward matcher.
And finally, this simple matching seems to work for almost all cases
of the "find analogy" tasks as well.@FOOT[
As we will discuss later,
this success can be attributed to
the fact that the analogues have very accomodating representations,
one which often explicates the desired mapping.
This is, in turn, a by-product of the fact that
the person who describes the analogues
usually has a similar background to the person who will use these facts,
and so encodes these analogues in a way which makes the analogy transparent.
See discussion of reformulation, below.]
We will now elaborate these virtues.

@SubHeading[Description of tasks]
We consider first the @i[Analogy Finding] tasks:
@BEGIN[ITEM1]
"Find the analogy joining two analogues" is equivalent to finding a mapping
@G[s]: [features of analogue 1] @K[LeftArrow] [features of analogue 2].

"Find the other analogue" is equivalent to finding an object, @G[a]@-[2],
which embodies (satisfies) the facts in the range of
@G[s]@K[LeftDoubleBracket] @G[a]@-[1] @K[RightDoubleBracket].
(Recall that both @G[s] and @G[a]@-[1] are assumed given.)
@END[ITEM1]

This mapping formalism is even more adept at describing
a full range of @i[Analogy Using] tasks.
This is because the analogy itself is a well defined object
-- it is that mapping of (features of) one object onto 
(features of) the other.
This makes it relatively easy to analyze an analogy,
For example, one can describe the set of features which a
given analogy considers -- by listing the domain and range of the mapping.
Or one can (begin to) define the goodness of an analogy as a weighted
sum of the component associations.

One can also compare or rank analogies, by applying well-defined measurements
to these mapping.
For example, one analogy is more complete than another if the 
mapping of the first extends that of the second.
Similarly, with the proper measuring system
one decide which proposed analogy was most useful...

The most familiar "analogy use" task involves
conjecturing a new fact about (one of) the analogues.
This can be achieved by
extending the analogical mapping,
to now take additional parts/features/ ... of one analogue,
and map them into some correspondents in the other analogue.

@SubHeading[Difficulties]

While any of these tasks can be stated using this mapping formalism,
many are still is quite difficult to perform.
Consider first the "analogy finding" tasks --
in particular, the "find the analogical mapping, given the analogues" task.
Realize the approaches implied by this formalism
(two of which were discussed earlier in this chapter,)
provide no guidance in constructing the analogy.
That is,
the fact that we are seeking a mapping says nothing about the contents
of this mapping.
For example, at this level nothing precludes the possibility
that each fact about one analogue is mapped onto an arbitrary fact
about the other.
Clearly this is not what is intended by the term @i[analogy].
There should be some contraints on what features of the first analogue
should be mapped over,
and (possibly) other constraints which limit their image
-- i.e. the corresponding features of the second analogue.

To elaborate this, imagine constructing an analogy mapping between
@I[Analogue@-{1}] and @I[Analogue@-{2}].
What does it mean to say that the
@I[F@-{1}] feature of @I[Analogue@-{1}] should correspond to the
@I[F@-{2}] feature of @I[Analogue@-{2}].
All we know is that 
@I[F@-{1}] should be similar to @I[F@-{2}],
and that this new @I[F@-{1}] - @I[F@-{2}] correspondence should
extend the original @I[Analogue@-{1}] - @I[Analogue@-{2}] mapping.

What can we say about this extention?
First, the result must be a function,
and should be consistent@FOOT[whatever that means]
with the original map.
Beyond these "syntactic" constraints,
a good analogy should also be "semantically" meaningful.@FOOT{
<<is this relevant, here or later??>>
This often means that this transformation
was justified by some known fact or rule about the world.]
Finding @i[meaningful] extentions is what makes analogizing so tricky.}

The fact that most programs use a body of rules
to indicate what types of facts and features should be considered
does not obviate this problem.
What motivated those rules?
Clearly nothing intrinsic to the fact that this is a mapping.
(I.e. these rules can be viewed as embellishments to a mapping scheme,
but there are not needed to produce a mapping.)
The next chapter will discuss a different formalism of analogy
which supplies this "direction" needed to construct an analogy.

Consider now a different "analogy finding" task:
Imagine, instead, being given only one analogue
and a description of the desired analogy,
and asked to find the best analogue to fit this situation.
(E.g. find a legal case which ...)
It is not clear how to use the above mapping model of analogy for this purpose.

A final "analogy finding" task is the familiar case
-- asking how a collection of objects are all similar.
Given that this is NOT merely the O(n@+[2]) pairwise analogies,
it is apparent that there is no way to describe this case of analogy as
a mapping.

This covers the difficulties associated with "analogy finding" tasks.
"Analogy using" tasks seem both easy to state and relative easy to solve,
in the general case,
modulo the problems which the next topic, "Reformulation", will address below.

@SubHeading[Other Issues: Reformulation]

Another issue, reformulation,
is, perhaps, the central problem of analogy understanding,
as is, at some level, independent of the formalism used to describe analogy.
However it plays such a prominent role in both defining and using a mapping
that this issue is best discussed here.
(That is, whle none of the approaches included in this paper 
will come close to resolving this problem, this mapping approach does the
worst.)

When we mentioned that the analogical mapping can be used to carry some 
fact about one analogue onto a corresponding fact about the other
it is usually assumed that these "facts" would be simple --
dealing with, say, a pair of constant symbols,
or some pair of propositions, which are of the same arity,
and usually employing the same relation symbol.
It is important to realize how crucial a role
the representations of the analogues played
in both defining the mapping and in using it.
(We were hinting at this way back in footnote @Ref[?].)
<<Here: give example -- #deaths in Hamlet, as a slot, helps.  Compare with
English text.  Or consider presense of term for ROOT of a tree...>>

Analogies, here, are very tied to the representation used.
If the analogues are not in correct form,
there is very little one can do.
However, realize that these features, ideally,
should depend on the analogues themselves,
and not on their representations.

<<here - expand this, perhaps>>

@SubHeading[Other Issues: Learning]

Another issue is learning.
The result of the analogy question is a rather specific mapping.
How could this information be used for some subsequent task?
As it deals so specifically with this pair of analogues, it is hard
to see how it could then be applied to a different situation.
This behavior does not fit well with the desired behavior of an analogy
understanding mechanism.

The underlying reason is that the "common features" 
which connect the analogues are never explicitly noted.
This means, first, that learning (as a side-effect) will not occur.
(That would be measured in terms of speed up of performance, or ...)
It also makes it impossible to create
an inventory of analogues,
(usually manifest as "commonalities",)
or to exploit an existing collection.
Such information, we will see in the next chapter, is very useful
in guiding the construction of other analogies.

Realize that an acknowledgement of the commonality of the analogues
is very much needed.  Here, it is just not explicated.

@SubHeading[Conclusion]

In a nutshell, we see that the mapping approach
is pretty good for tasks which involve using the analogy,
but provides little help for tasks which are attempting to find an analogy.

@Chapter[Commonality]

Notice that the analogies defined as a mapping in the previous chapter,
were based on the ways in which these two analogous @i[DIFFER].
This approach is, instead, explicitly capitalizes on the similarities
shared by the two analogues.
(In that sense it follows from the @i[Similar]ity relation discussed in
Section @Ref{Similar}.)

As with the previous chapter, we will consider two subcases of this approach.
These differ in how that common set of features will be stored
-- as a class or as a theory.
After presenting these two approaches we will summarize the merits and
shortcomings inherent in both manifestations of this 
@i[Commonality] view of analogy.

@Section[Common Theory]
@Label[CT]

Here we consider a model-theoritic approach to analogy,
where we consider two objects to analogous if there is some common theory
which each analogue satisfies.
This would mean that the @T[Analogy] relation takes three arguments:
a pair of models, (@i[viz.], the analogues) and that common theory.@FOOT[
We will, for convenience, deal with theories written using the conventions
of Predicate Calculus, PC.
There are many other formal representations which would do as well.
We chose PC, basically, because it comes with a 
well-understood (Tarskian) semantics,
and an accepted body of rules of inference.
Also, we are NOT limit ourselves to first order PC,
or to a calculus which lacks any explicit meta-level information --
in fact a good many of our rules are at those "higher" levels.]

For example, 
@BEGIN[Example]
(ANALOGY @B[Z] @B[R] GroupTheory)
@END[Example]
would be a true statement, as would
@BEGIN[Example]
(ANALOGY "Fred" "Mary" T@-[FM]),
@END[Example]
where 
T@-[FM] includes facts like "@B[(MEM ** Lawyer)]",
with the understanding that the appropriate instantiation of "**"
is the individual Fred in the case of the first model, and
Mary in the second case.

The summary section, @REF[S-C], will discuss many of the features,
both pro and con, will this commonality approach,
concentrating in particular on the types of tasks which this can be
described within this formalism.
The remainder of this section will discuss specific features of this
common theory approach.

<<rewrite this paragraph>>
Notice, on the positive side, that the two analogues need not be
be described in the same language --
the interpretation process associated with model-theoritic satisfaction
does all of these mappings.
While this does not solve the reformulation problem mentioned above,
(after all, one still has to describe the analogues in some manner,)
it does remove it one level.
Note that any two representations of an objects are, by this definition,
analogous.  This is NOT true under the mapping view of analogy.

This language independence is a double-edged sword.
One obvious problem is how to determine which terms in one
analogue correspond to which terms in the other.
(This is true for both analogy finding and analogy using tasks,
as neither case (explicitly) includes the pair of instantiation mappings.)

@Section[Common Class]
@Label[CC]

This approach is almost identical to the prior Common Theory case.
Here, instead of satisfying a common theory,
two analogues are deemed analogous if they belong to the same set --
i.e. if they both satisfy the same unary predicate,
denoting the characteristic function of that set.
The equivalancy is apparent when spelling out the terms for membership
in this set 
-- which may be only when some arbitrary formula is true for that object.

For example, we may consider @B[Fred] and @B[Mary] to be analogous as
they are both lawyers -- i.e. 
@B[Lawyer(Fred)] and @B[Lawyer(Mary)] are both true.
This is clearly isomorphic to the
@B[(MEM ** Lawyer)] case used in the common theory situation.

As a more complicated example, suppose we observed that
@B[Fred] and @B[Mary] were analogous as they both attended a good school.
Here we would write that
@B[AttendedGoodSchool(Fred)] and @B[AttendedGoodSchool(Mary)] are both true,
where
@BEGIN[Example]
AttendGoodSchool(x) @K[IFF] @K[Exists] s. [Attend(x,s) @K[AND] GoodSchool(s)].
@END[Example]
In the earlier case, we would have defined a AGS theory, which consists of
the sentences
@BEGIN[Example]
Attend(** GS)
GoodSchool(GS)
@END[Example]
where the symbols @B[**] and @B[GS] denote constants, which are instantiated
by @B[Fred] and @B[CalTech] in the case of the first analogue; and
by @B[Mary] and @B[Stanford] in the other case.
Notice we had to generate skolem variables, in both cases --
the "s" in the current Common Class case, and that "GS" constant
when dealing with a common theory.

This remainder of this section will describe aspects on
this "Common Class" formalism,
concentrating on how it differs from its sibling, the "Common Theory" approach.

First, the common class does not need to pre-defined,
any more than the common theory has to already exist before we could
instantiate it to the two models.
Second, class membership is encoded using the characteristic predicate
of this set,
which has some associated "semantics" --
that defining sentence which follows the @K[IFF] sign above.

When we want to discuss a complex relation 
-- as @B[AttendedGoodSchool] was --
we are forced to discuss its parts or "sub-features".
This is easy, using the "skolem" functions shown above.
(Recall that, again,
the CT approach requires something isomorphic to this as well.)
While this seems, somehow, unclean, it does seem 
sufficient to handle any situation.

One place where CC differs from CT is in terms of the language used
to describe the analogical connection.
(e.g. the "as both are @i[x]", or "except that it is @[y]", ...)
Both analogues must be described in the same language -- as
both must satisfy the same predicate.
Hence the problems associated with having different languages do not arise.
Of course, neither do its advantages --
especially wrt reformulation, and general versatility.

Also, everything which can be stated (is forced to be) in first order PC,
i.e. avoiding the hassles associated with meta-level.
(And, again, providing none of the advantages either.)
@Section[Summary of Commonality Approach]
@Label[S-C]

Before listing the types of tasks which can be tackled using this formalism,
we will first discuss some other comments about this commonality approach.
First, it clearly is a nice extension to the notion of @i[Similarity] --
once again we are discussing just how two objects are similar.
Second, here it is possible to maintain a collection of to be considered
analogies, which can guide analogy generate tasks.
<<here - anything else?>>

@SubHeading[Description of task]

Both commonality formalisms,
(like the earlier mapping approach,)
are capable of describing almost any analogy task.
Most "analogy using" tasks are easily stated,
as the analogy itself is quite explicit -- it is that common theory,
or predicate.
Thus we can readily compare two analogies,
and as readily define measures for evaluating how good an analogy is.

The other standard "analogy use" task is deriving new facts about
one of the analogues.
By force of the definition of analogy,
each analogue must satisfy a certain theory or predicate.
This means that we can produce the precise (set of) sentences which 
the unfamiliar analogue --
those facts which follow from instantiating that common theory or
which must be true for the common predicate to be satisfied.
Hence we can explicitly state what facts @i[must] be true for this analogue.
Beyond these guaranteed statements,
we can go on conjecture other facts, based on these now-given facts.
<<Here - give an example>>
Finally, realize that these manipulations reduce to well defined PC inference
methods -- such as instantiation, or satisfaction.

What about "analogy finding" tasks?
Consider first the "find the other analogue" case.
This is relatively easy, requiring only that we find some model for a theory
within some domain, where that theory is the analogy, and the domain comes
from the "analogizing" context.
Notice that the first analogue appears to play no role in this situation.

The "generate the common theory from the analogues" problem is also
easy to state.  It is, however, harder to solve.

@SubHeading[Difficulties]

Consider our canonical "A is like B within constraint @G[a]",
and imagine how to generate the theory which both A and B will have
to satisfy.
(As the common predicate case is essentially identical to this, we will
not deal with it as well.)

It is easy when this @G[a] is a positive instance.
This means that both analogues must satisfy some property,
e.g. "both are lawyers", or "in terms of profession".
Here the common theory just includes that common statement.
<<here: two notes:
(1) may have to abstract the particular relation
	[tree case]
(2) may have to then propagate the effects of this.>>

"Negative instances", 
which specify that something is NOT true for one analogue,
is more difficult.
The trick is to specify, in meta-theory,
what relations are to included, and which excluded,
from sentences which can appear in this common theory.
The "excluding gender", or "except that he is male" cases
can be solved by declaring that the "Gender" relation must not appear in
the common theory.

"Substitutive cases",
such as the "after substituting CalTech for Stanford" example,
seem impossible to state in this formalism.
How can a single theory indicate a pair of things,
where exactly one is true of each analogue.

@SubHeading[Other Issues: Learning]

The fact that one can accumulate a host of common theories is
another advantage to this approach.
This inventory can provides some direction for finding the analogy.

One may have some general "abstractions" ...
(More on this in general comments re: Commonality.)

It is because there 
are some general rules about the world which can be exploited,
that this formalism for analogy makes any sense.

@SubHeading[Other Issues: Correspondences]

The remaining problem is how to establish the correspondences.
To what does the x of A map?  
While this information is part and parcel to the other approach, mapping,
here the information is unavailable.
<<here - give an example>>

@SubHeading[Other Issues: Reformulation]
<<Here - mention that this remains an issue>>

@SubHeading[Conclusion]

Here the analogy use task are rather straightforward,
as we again have an explicit handle on the analogy itself.
Tasks which require the analogy to be found, or generated,
vary considerably in difficulty, depending on the nature of the constraint.
Note that "analogy finding" is here defined -- it is possible to have
a catalogue of known analogies, and use this to find the analogy.
(Recall every mapping had to be generated.)

@Chapter[Answer: Common theory + Mappings]
@Label[Answer]

Our solution involves taking the best from both worlds --
the idea of mappings remains, as does the notion of capturing a commonality.
Here the analogy relation takes five arguments:
in addition to the pair of analogues themselves,
(or more precisely, a pair of descriptions of those objects,)
this proposition will include a common theory, (which both analogues "satisfy"),
and a pair of mappings, which each map sentences from that common theory to each
analogue theory.

Note this permits us to include both the similarities of the analogues
(using the common theory) and their differences -- stored by noting what
maps to what.

<<here>>
Before presenting more details of "the answer",
we will mention ...
After those details
we will illustrate that this does seem to cover all the situations we
have seen thus far.

Can't really claim to be new 
-- this is related to the idea of finding a sibling on the "generalization"
tree -- found by first generalizing one analogue, and then specializing.
That generalization is (isomorphic to) the CT, the generalization process is
@g{s}@-{1}, and the specialization is 
@g{s}@!@-{2}@\@+{-1}.  
(Our version is a more symmetric version.)
@i{C.f.} @Cite[Polya1], p.16.

VII. Remaining issues:
  A. Symbol to Symbol doesn't work 
    i. Examples:
	ON2 => ON3
    ii.  Soln: sentence to sentence mapping
	Still, want some notion of consistency
	Standard recursive decomposition not adequate
  B. Satisfies desired propoperties of analogy?
	[here list some props, and show that it does.]

Problem:
Where is the analogy?  How to compare two analogies -- there is no single
thing, like a theory or a mapping, to grab onto...

Seeing that the previous approaches were lacking,
we conclude that, to be adequate, the analogy relation must have five terms --

@SubHeading[Critique]

Solves instantiation issue, and hence leads to mappings (see Chapter @Ref[F-F].)
Symbol-Symbol doesn't work -- see next section)


Difficult to compare analogies -- as may be totally different.
(This just stems from added complexity, and may not be part and parcel
of ...)
Can handle both finding and usage of analogy -- by two parts.

needs sentence to sentence mapping
	Here want to have some notion of consistency
	Standard decomposition not adequate
Define
@BEGIN[Example]
ANALOGY( A@-{1}, A@-{2}, CT, @g{s}@-{1}, @g{s}@-{2} ) @K[IMPLIES]
	CT @K[NEQ] @K[EMPTYSET] @K[AND]
	CT @K[SUBSET] ( @g{s}@-{1}[ A1 ] @K[INTERSECTION] @g{s}@-{2}[ A2 ]) @K[AND]
	CONSIST-PRESERVE( @g{s}@-{1} ) @K[AND]
	CONSIST-PRESERVE( @g{s}@-{2} )
@END[Example]
where @g{s}@-{1}, @g{s}@-{2} are partial mappings, and
CONSIST-PRESERVE( @g{s}) means
@BEGIN[EXAMPLE]
	@K(ForAll) X. CONSIST( X ) => CONSIST( @g{s} ),
@END[EXAMPLE]
where CONSIST(X) means the theory X is consistent.
Also, CT, A1 and A2 are all theories.

	Perhaps add in something like Satisfies( Model(A1), CT) ? or whatever.

  We want to impose further restrictions on @g{s}@-{1}, to prevent them from mapping
  non-tautalogies into tautalogies, etc.  (Currently on sentence-sentence)
  And what else?

------
@Chapter[Remaining Issues]
@Label[Issues],
 mapping sentence to sentence
	[Take ON2 vs ON3 case]

Satisfies properties of analogy?

Does Analogical inference have to be meta-level?  Sure seems that way.

Currently:
@BEGIN[Example]
@B[Given:] @!Analogues a and b
@\A@-{1} = Th'(a) 
		B which is B @K[SubSet] Th'(b)  [call Th'(b) = A2]
		Analogous( a,b )
	Find:	@G[t] @K[MemberOf] A2 - B ... i.e. new fact about b, ...
@END[Example]
where @!Th'(@g[a]) = axioms of @g[a], but NOT their deductive closure;@*
and @\Analogous( a,b ) @K[IFF] ∃ CT, @g{s}@-{1}, @g{s}@-{2}.@~
Analogy( Th(a), Th(b), CT, @g{s}@-{1}, @g{s}@-{2} )

A basic intermediate step is
@BEGIN[Example]
ANALOGY( A1, A2, CT, @g{s}@-{1}, @g{s}@-{2} )
@G[t] @K[MemberOf] CT
-----------
@g{s}@-{1}( @G[t] ) @K[MemberOf] A1
@END[Example]

Hence
@BEGIN[Example]
ANALOGY( A1, A2, CT, @g{s}@-{1}, @g{s}@-{2} )
@G[t] @K[MemberOf] A@-{1}
-----------
@g{s}@!@-{2}@/@+{-1}[ @g{s}@-{1}( @G[t] )] @K[MemberOf] A2
@END[Example]

where @g{s}@!@-{2}@/@+{-1} is inverse of @g{s}@-{2}.

@Chapter[Acknowledgements]

Our (respective) advisor and ?collaborator? Prof Douglas Lenat.
Thanks to Prof Lindley Darden,
and useful comments from
Tom Dietterich,
Patricia Schooley,
and Steve Tappel.
@CHAPTER[Notes]

@BEGIN[ITEMIZE]


@BEGIN[Multiple]
@Tag[Gen-Use]
This side comment is addressed to those "procedural-ists" who regard an analogy
as a process which takes some inputs and returns some output:
It is very tempting to split the types of analogizing tasks into two partitions --
those which generate/specify an analogy, 
(@i[e.g.], those programs which generate the desired mapping,)
and those which use or understand the analogy -- for example, those programs
which use the given analogy (perhaps the mapping)
to further specify some property of one (or both) of the analogues.

For illustration, consider the following extreme examples: 
@BEGIN[Example]
"How is learning at CalTech like sipping water from a fire hose?"
@END[Example]
is clearly in the first camp.
The goal here is to specify that feature which is common
to both @i["learning at CalTech"] and @i["sipping water from a fire hose"]
analogues --
perhaps that, in both cases, a vast amount of material is being forced into
the student/drinker at a flowrate far beyond his capability to absorb it.
At the other end of this spectrum,
@BEGIN[Example]
"Electricity is like Water flow in that both involve the
movement of some material through some specified course"
@END[Example]
fits nicely into the second category.
Here the analogy is quite well defined; the challenge is to
determine new properties from the Electricity analogue, based on both
facts known about Water Flow, and about the well-specified connection --
that both involve movement of something along a course.

We will see later that this distinction betseen analogy-specification
and analogy-use is usually fuzzy; if not altogether meaninglepπfL@~∃∪\↓↓πSi∃7≥CSYKβ]C1←Os:↓∩AG←9UKGiUeJAi!Ch@~)E←iP↓C]CY=H∂eβ>+;↔K∂#'?9ε;⊃β∞sπ3??IβWN*{W;∪/∪OSπv#';≤hSOβ?.c⊃β∂x¬V*π]lF/∩
V∞ε≥lrε}d⊗v∞M|wJπ,XfNv]\Vw"aQ$.vD	v"εM≤w⊗/>9⊗}raQ$∧,hK4o.NM↔εf[QPPh(λ$,<→k4o.NM↔εfXπ#!(∃_9k:≥{pl≡y<w!QUy(
\>(≤L\x8Y∧(∪⊂↔Ytqpvλ22y4]0z4w[⊂0qFB !"cRg Exampl@∃:~∃↓≥wa|Q∧R~∃↓≥wg|QλR~∃↓≥we|Q∧Y∧R~(@@\\8~∀4T
:ε2|:e"¬bα↓1↓rq9$∀R↓↓99ph(4*v+↑≠π∨!"	$hRα⊗:%Z↔cπoβ3⊗thS←#↔⊗)βS#∂ 4*α?[Cy"
IβK↔4+CMβ&yβ¬β⊗{∪eβ|∧bε6≤>G4_8[n↑λ≠{LT≠yH∞M→(_-l;≠yn\<kλλ⊃"J≤↑Z⊂<∞4≤{s,T_{{M.9Xu∧λ⊃}|∂h>l/@∀ TP⊂%m`g⊃,P↔↔⊂ %mPg".P⊂#⎇x?⊂⊗⎇g?
 TV∀CE0w2λ64ur]tyrFB #⎇y←∀!∀P~7v29H:42P→0qz9H5w7{[⊂0q7]z⊂:4→P7z4→y⊂ w_v7szYP!↔εB*42P≤2vpt[4w3@⊂#⎇y?
 V!∀H:2v&≤how A and B are known to interrelate.
(Any of these statements may be empty.)
From these assertions we are able to form a (sub)conclusion that
A and B are analogous, encoded by the
@B[ANALOGY(A, B, ...)] statement above.
This, together with possibly other facts enables us to derive a new fact
about A (or about B, or about the connection joining these objects).

"Analogy finding" is the first part of this process, which ends when
@B[ANALOGY(A, B, ...)] statement can be proven.
"Analogy use" begins there, and leads to new statements about the analogues, ...

Note that we are @i{not} committing ourselves at this point on
what types of derivations must take place to reach these 
@B[ANALOGY(A, B, ...)] or @B[NewFact(B)] conclusions.
If the standard logical inference steps (e.g. modus ponens and friends)
are sufficient they alone will be used, based on various rules.
Otherwise we may have to define other types of derivation steps.

As an example of this find versus use dichotomy,
consider
@BEGIN[Example]
(MEM MRG PERSONS) & (NUMBER-ARMS MRG 2)
(MEM RDG PERSONS)

>>Now pretend we have the naive rule:
>>	@K[ForAll] $x, $y, $c. @u[IF] ( (MEM $x $c) & (MEM $y $c) )
>>		@u[THEN] ANALOGY($x $y).

ANALOGY(MRG RDG)

>>Everything above is considered "analogy finding".
>>Now for "analogy use".

>>Here pretend that we had the ridiculous rule:
>>	@K[ForAll] $x, $y, $r. @u[IF] ( ANALOGY($x $y) & ($r $x 2) )
>>		@u[THEN] ($r $y 2).

(NUMBER-ARMS RDG 2)

@END[Example]
@END[Multiple]

@BEGIN[Multiple]
@TAG[NeedReform]
Analogy is (or should be) a "semantic relation",
which deal with a pair of objects, not only with their descriptions.
Given our total knowledge of integers, this was not much of a limitation --
as we could, (in theory if not in practice) store all relevant facts about
the integers.
We do not have this liberty when dealing with real world objects.
Here the given description of the object may not
explicate (or worse, not even include) the features
which should be in correspondence, for this analogy.
This problem points to the necessity of reformulation for
any sophisticated analogizing program -- that is, the program must be
able to find a different representation for (one or both of) the analogues;
in which the desired commonality is expressed.}
@END[Multiple]

@BEGIN[Multiple]
@TAG[Dims]
One can think of each of these cases as a point in the two dimensional space,
whose axes are:
@BEGIN[ITEMIZE]
The "Formal"ness of this Analogy,@*
measured by determining how many of the analogues (0, 1 or 2)
are formal, (as opposed to natural,) objects.

"Pre-existence" of the (common) theory,@*
That is, whether the hearer was aware of the underlying unity of the
two analogues before presented with this analogy.
@END[ITEMIZE]
The examples given in Chapter @Ref[Examples] should help elucidate
these dimensions.
@END[Multiple]

@TAG{ContextDep}
Determining this similarity might involve various contextual considerations.
Hearing that "Fred is like Jill in that both are tall."
does not mean that @b{Fred}:@i{Height} = @b{Jill}:@i{Height},
as Tall for men has a different meaning (in terms of absolute meters) than
Tall does for women.
(Of course, this @i{Height} slot records the absolute height of the individual in,
say, meters).
What we really meant was that their respective @i{QualitativeHeight} slots
match -- as both have the value Tall.
The particulars (@i{i.e.}, cutoff values)
used to compute this value will be different for men than for women.
@END[ITEMIZE]

@Unnumbered[References]
@Bibliography

@BEGIN[Comment] 	Outtakes


Hence the underlying, unifying commonality may or may not be obvious
within a particular description.

-----
We went on to note that this type of description could be used to
define the analogy itself.

This skeletal description should be viewed only as a conventient formalism.
What qualifies for that constraint, @G[a]?  
And what does each such type of constraint @i{really} mean?

@Foot[
Note that in many situations
(@i{e.g.}, when the problem situation provides the needed context,)
this contraining clause is implicit in the problem statement,
and does not need to be explicitly mentioned.])

There are several techniques for finding consistent "completions"
(or "closures") of a mapping.
<<here - give some examples>>
These extending techniques, however, need to be guided.
Fortunately, it seems there are, in fact, 

Other tasks involve the use of an analogical connection:
<<here - what other tasks?>>
We mentioned above that directing an analogy is difficult.
Which features should be mapped over?

[need to indicate definitional vs assertional -- but this could be handled
with proper meta-level]

Now can generate new facts, by various solid (i.e. valid) rules
of inference, as are working with a body of axioms.

@END[Comment]